New programs created by a computer programmer often include one or more inadvertent errors. Locating and removing the errors in a program is generally known in the industry as "debugging" the program, the program errors being referred to as "bugs".
Debugging a program can be difficult and time-consuming. In the prior art of debugging a program, a programmer may first read the program line-by-line to try to locate the errors. Following the flow of a program by reading it line-by-line is difficult, even in a relatively simple program. If the program contains many loops, subroutines based on variables, or calls, the programmer may not be able to trace the sequence of execution, and hence the function of each line.
Computer programs are generally written in a high level programming language. This high level language, often referred to as source code, is translated by a compiler program into an assembly language. The binary form of the assembly language, called object code, is the form of the code actually executed by the computer.
Code debuggers are programs which aid a programmer in finding errors in code. They are extremely useful tools for improving the efficiency of the code debugging process.
One form of tool for debugging computer programs is disclosed in U.S. Pat. No. 4,636,940. It is pointed out that in many development situations, there may be bugs in both the hardware and the software. To simplify the debugging process, a logic analyzer is provided that can continually adjust during run time the "real" absolute trace specification to match the symbolic one entered by the user. It also can properly insert source symbols into the trace listing, even though the trace pertains to a program whose position in memory was determined dynamically at run time.
U.S. Pat. No. 5,021,948 points out that it is difficult to correlate a computer program statement number with a program statement, and that it is difficult to recognize program control structure and program flow because of loops, and the like. That patent discloses displaying a program counter mark showing program flow and control structure in correspondence with the program list.
U.S. Pat. No. 4,734,854 teaches that a software system may consist of several modules, each performing a specific task. That patent also discloses that commonly used software modules may be designed and developed only once, and reused many times in different applications with different operational contexts and requirements.
U.S. Pat. No. 4,595,981 discloses a method for testing interfaces between computer program modules. The individual cause/effect charts of each of the modules are used to test the interfaces between the modules by executing the test cases in the charts in such manner that each test case need only be executed once. The variables passed between modules are monitored and compared with the input conditions in the charts.
U.S. Pat. No. 5,038,348 discloses apparatus for debugging a data flow program. That patent points out that some computers do not operate on the principle of successive execution of instructions by the program counter. Instead, execution of an instruction is permitted as soon as all the data for calculation are prepared. The patent discloses a debugging apparatus for effectively carrying out debugging of a data flow program which can be executed in a data flow type information processing apparatus.
U.S. Pat. No. 4,953,084 discloses a source level debugger. When a programmer writes this program in a high level language, he does not want to search for the appearance of bugs or programming errors in the assembly code. To avoid these problems, debugger programs are provided that allow a programmer to debug his program with reference to the level of code in which he originally wrote the program. Such a debugger program is called a source-level debugger. Since the computer operates on object code, a source-level debugger needs to know where user resources named in the source code are actually stored by the computer during operation so that when a user requests the current value for a user resource, the debugging program knows where to find the user resource. This patent teaches the use of variable ranges to support symbolic debugging of optimized code. A debug symbol table is constructed which include descriptions of each user resource in source code. Additionally, a range table is constructed containing a list of ranges and a description of where the user resource may be found during each range.
U.S. Pat. No. 5,124,989 was issued to Microsoft Corporation for a method of debugging a computer program. That patent refers to a prior art product sold under the tradename Codeview. The patent discloses an improvement over the Microsoft Codeview debugger. The patent teaches storing a record of all debug commands executed on a program to facilitate locating and ensuing correction of errors in the program. The patent also teaches repeated identical execution of a sequence of debug commands on a program to observe the program response, both before and after modifying the program.
Despite all of the prior art patents such as the representative ones listed above, there is still a need for improvements in the field of debugging computer programs. A long standing problem with symbolic debuggers is the size of symbolic debug information.
Compilers supply symbolic debuggers with information needed to allow high level language inquiries. For example, the data type of each variable and function is part of this information. This information is referred to as "symbolic debug information" or just "SDI".
The size of SDI can get large enough to make a noticeable impact on the size of a program and the speed of a debugger. The debugger is slowed because it may read through all the SDI when first processing the program to be debugged.
Almost all programs are developed as collections of separate "source modules," each separately compiled. The output from each compilation is called an "object module"; it contains the translation of the program into machine language and, typically, the SDI generated for the source module. The object modules generated from all the source modules are combined into a single program by a program called a "linker." The combined output contains the SDI as well as all of the translated machine language.
The problem: there is a large quantity of redundant SDI in programs made of separately compiled source modules. This is because these separate source modules almost always share common source code of the program--placed in so-called "header files", and the SDI for a single header file shared by two different source modules is contained in both object modules.
With the relatively new language C++ rapidly growing in popularity, the problem is becoming worse, due to peculiar characteristics of the C++ language in which extensive program source code is contained in the header files. The industry has spent a lot of effort trying to reduce the redundancy. According to Eric Engstrom of Microsoft Corporation, over two man years was invested in a Microsoft program called `CVPACK` (Codeview pack), which is a utility whose primary task is to remove redundancy from SDI. (Codeview is the name of Microsoft's debugger, and "Codeview records" is a term commonly used to describe the form of Microsoft's SDI.)
There is a need to reduce the generation of redundant SDI. This problem is primarily found in connection with C and C++ programs, although the problem can arise in connection with other languages as well.
The advantages of the reduction of the generation of redundant SDI are as follows:
saves space in program files; PA1 speeds up debuggers because they can load less SDI; PA1 speeds up the compilers that produce SDI, because they produce less redundant SDI.